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Abstract 


The Point-to-Point Protocol (PPP) provides a standard method for 
transporting multi-protocol datagrams over point-to-point links. 


The PPP Compression Control Protocol provides a method to negotiate 
and utilize compression protocols over PPP encapsulated links. 


Microsoft Point to Point Encryption (MPPE) is a means of representing 
PPP packets in an encrypted form.  MPPE uses the RSA RC4 algorithm to 
provide data confidentiality. The length of the session key to be 
used for initializing encryption tables can be negotiated.  MPPE 
currently supports 40-bit, 56-bit and 128-bit session keys.  MPPE 
session keys are changed frequently; the exact frequency depends upon 
the options negotiated, but may be every packet. MPPE is negotiated 
within option 18 in the Compression Control Protocol. 


This document describes the method used to derive initial MPPE 
session keys from a variety of credential types. It is expected that 
this memo will be updated whenever Microsoft defines a new key 
derivation method for MPPE, since its primary purpose is to provide 
an open, easily accessible reference for third-parties wishing to 
interoperate with Microsoft products. 


MPPE itself (including the protocol used to negotiate its use, the 
details of the encryption method used and the algorithm used to 
change session keys during a session) is described in RFC 3078. 
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1. Specification of Requirements 


In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 
"recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as 
described in [6]. 


2. Deriving Session Keys from MS-CHAP Credentials 


The Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP-1) 
[2] is a Microsoft-proprietary PPP [1] authentication protocol, 
providing the functionality to which LAN-based users are accustomed 
while integrating the encryption and hashing algorithms used on 
Windows networks. 
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The following sections detail the methods used to derive initial 
session keys (40-, 56- and 128-bit) from М5-СНАР-1 credentials. 


Implementation Note 


The initial session key in both directions is derived from the 
credentials of the peer that initiated the call and the challenge 
used (if any) is the challenge from the first authentication. 

This is true for both unilateral and bilateral authentication, as 
well as for each link in a multilink bundle. In the multi-chassis 
multilink case, implementations are responsible for ensuring that 
the correct keys are generated on all participating machines. 


2.1. Generating 40-bit Session Keys 


MPPE uses a derivative of the peer's LAN Manager password as the 40- 
bit session key used for initializing the RC4 encryption tables. 


The first step is to obfuscate the peer's password using the 
LmPasswordHash() function (described in [2]). The first 8 octets of 
the result are used as the basis for the session key generated in the 
following way: 


/* 
* PasswordHash is the basis for the session key 
* SessionKey is a copy of PasswordHash and is the generative session key 


* 8 is the length (in octets) of the key to be generated. 
* 


T, 
Get Key(PasswordHash, SessionKey, 8) 


/* 
* The effective length of the key is reduced to 40 bits by 
* replacing the first three bytes as follows: 


ху 

SessionKey[0] = Oxdl ; 
SessionKey[1] = 0x26 ; 
Sessionkey[2] = 0x9e ; 


2.2. Generating 56-bit Session Keys 


MPPE uses a derivative of the peer’s LAN Manager password as the 56- 
bit session key used for initializing the RC4 encryption tables. 


The first step is to obfuscate the peer’s password using the 
LmPasswordHash() function (described in [2]). The first 8 octets of 
the result are used as the basis for the session key generated in the 
following way: 
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/* 
* PasswordHash is the basis for the session key 

* SessionKey is a copy of PasswordHash and is the generative session key 
* 8 is the length (in octets) of the key to be generated. 

* 

*/ 

Get Key(PasswordHash, SessionKey, 8) 


/* 
* The effective length of the key is reduced to 56 bits by 
* replacing the first byte as follows: 

Ж/ 

SessionKey[0] = Oxdl ; 


2.3. Generating 128-bit Session Keys 


MPPE uses a derivative of the peer's Windows NT password as the 128- 
bit session key used for initializing encryption tables. 


The first step is to obfuscate the peer's password using 
NtPasswordHash() function as described in [2]. The first 16 octets 
of the result are then hashed again using the MD4 algorithm. The 
first 16 octets of the second hash are used as the basis for the 
session key generated in the following way: 


* 


Challenge (as described in [9]) is sent by the PPP authenticator 
during authentication and is 8 octets long. 

NtPasswordHashHash is the basis for the session key. 

On return, InitialSessionKey contains the initial session 

* key to be used. 

ху 

Get_Start_Key (Challenge, NtPasswordHashHash, InitialSessionKey) 


+ + + o М 


/* 
* CurrentSessionKey is a copy of InitialSessionKey 
* and is the generative session key. 

* Length (in octets) of the key to generate is 16. 
* 

*/ 


Get Key(InitialSessionKey, CurrentSessionKey, 16) 
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2.4. Key Derivation Functions 
The following procedures are used to derive the session key. 


/* 
* Pads used in key derivation 


*/ 


SHApad1[40] = 
(0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; 


SHApad2 [40] = 
{Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, 
Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, 
Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, 
Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2}; 


/* 
* SHAInit(), SHAUpdate() and SHAFinal() functions are an 
* implementation of Secure Hash Algorithm (SHA-1) [7]. These are 
* available in public domain or can be licensed from 
* RSA Data Security, Inc. 
* 
* 1) InitialSessionKey is 8 octets long for 56- and 40-bit 
* session keys, 16 octets long for 128 bit session keys. 
х 2) CurrentSessionKey is same as InitialSessionKey when this 
* routine is called for the first time for the session. 
*/ 
Get Key( 
IN InitialSessionKey, 
IN/OUT CurrentSessionKey 
IN LengthOfDesiredKey ) 
{ 
SHAInit (Context) 
SHAUpdate (Context, InitialSessionKey, LengthOfDesiredKey) 
SHAUpdate (Context, 5НАРаа1, 40) 
SHAUpdate (Context, CurrentSessionKey, LengthOfDesiredKey) 
SHAUpdate (Context, SHAPad2, 40) 
SHAFinal (Context, Digest) 


memcpy (CurrentSessionkey, Digest, LengthOfDesiredKey) 
} 


Get_Start_Key ( 
IN Challenge, 
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ІЧ NtPasswordHashHash, 
OUT InitialSessionKey) 
{ 
HATnit (Context) 

HAUpdate (Context, NtPasswordHashHash, 16) 
1AUpdate (Context, NtPasswordHashHash, 16) 
1AUpdate (Context, Challenge, 8) 

HAFinal (Context, Digest) 

memcpy (InitialSessionKkey, Digest, 16) 


о о о о 0 
т: 


2.5. Sample Key Derivations 


The following sections illustrate 40-, 56- and 128-bit key 
derivations. All intermediate values are in hexadecimal. 


2.5.1. Sample 40-bit Key Derivation 
Initial Values 
Password = "clientPass" 


Step 1: LmPasswordHash (Password, PasswordHash) 
PasswordHash = 76 al 52 93 60 96 47 83 Oe 23 90 22 74 04 af d2 


Step 2: Copy PasswordHash to SessionKey 
SessionKey = 76 al 52 93 60 96 47 83 Oe 23 9022 74 04 a£ a2 


Step 3: GetKey(PasswordHash, SessionKey, 8) 
SessionKey = d8 08 01 53 8c ec 4a 08 


Step 4: Reduce the effective key length to 40 bits 
SessionKey = dl 26 9e 53 8c ec 4a 08 


2.5.2. Sample 56-bit Key Derivation 


Initial Values 
Password = "clientPass" 


Step 1: LmPasswordHash (Password, PasswordHash) 
PasswordHash = 76 al 52 93 60 96 d7 83 Oe 23 90 22 74 04 af d2 


Step 2: Copy PasswordHash to SessionKey 
SessionKey = 76 al 52 93 60 96 47 83 Oe 23 90 22 74 04 a£ a2 


Step 3: GetKey(PasswordHash, SessionKey, 8) 
SessionKey = d8 08 01 53 8c ec 4a 08 
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Step 4: Reduce the effective key length to 56 bits 
SessionKey = dl 08 01 53 8c ec 4a 08 


2.5.3. Sample 128-bit Key Derivation 


Initial Values 
Password = "clientPass" 
Challenge = 10 2d b5 df 08 5d 30 41 


Step 1: NtPasswordHash (Password, PasswordHash) 
PasswordHash = 44 eb ba 8d 53 12 b8 «6 11 47 44 11 £5 69 89 ae 


Step 2: PasswordHashHash = MD4 (PasswordHash) 
PasswordHashHash = 41 c0 0c 58 4b d2 849 1c 40 17 a2 al 2f a5 9f 3f 


Step 3: GetStartKey (Challenge, PasswordHashHash, InitialSessionkKey) 
InitialSessionKey = a8 94 78 50 cf c0 ac ca 41 78 9f b6 2d dc dd b0 


Step 4: Copy InitialSessionKey to CurrentSessionKey 
CurrentSessionKey = a8 94 78 50 cf c0 ac cl dl 78 9f b6 2d dc аа ьо 


Step 5: GetKey(InitialSessionKey, CurrentSessionKey, 16) 
CurrentSessionKey - 59 а1 59 bc 09 f7 6f 14 a2 a8 ба 28 ff ec Ob 1e 


3. Deriving Session Keys from MS-CHAP-2 Credentials 


Version 2 of the Microsoft Challenge-Handshake Authentication 
Protocol (MS-CHAP-2) [8] is a Microsoft-proprietary PPP 
authentication protocol, providing the functionality to which LAN- 
based users are accustomed while integrating the encryption and 
hashing algorithms used on Windows networks. 


The following sections detail the methods used to derive initial 
session keys from MS-CHAP-2 credentials.  40-, 56- and 128-bit keys 
are all derived using the same algorithm from the authenticating 
peer's Windows NT password. The only difference is in the length of 
the keys and their effective strength: 40- and 56-bit keys are 8 
octets in length, while 128-bit keys are 16 octets long. Separate 
keys are derived for the send and receive directions of the session. 


Implementation Note 


The initial session keys in both directions are derived from the 
credentials of the peer that initiated the call and the challenges 
used are those from the first authentication. This is true as 
well for each link in a multilink bundle. In the multi-chassis 
multilink case, implementations are responsible for ensuring that 
the correct keys are generated on all participating machines. 
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3.1. Generating 40-bit Session Keys 


When used in conjunction with MS-CHAP-2 authentication, the initial 
MPPE session keys are derived from the peer’s Windows NT password. 


The first step is to obfuscate the peer’s password using 
NtPasswordHash() function as described in [8]. 


NtPasswordHash (Password, PasswordHash) 


The first 16 octets of the result are then hashed again using the MD4 
algorithm. 


PasswordHashHash = пай (PasswordHash) 
The first 16 octets of this second hash are used together with the 


МТ- Response field from the М5-СНАР-2 Response packet [8] аз the 
basis for the master session key: 


GetMasterKey (PasswordHashHash, NtResponse, MasterKey) 


Once the master key has been generated, it is used to derive two 40- 
bit session keys, one for sending and one for receiving: 


GetAsymmetricStartKey (MasterKey, MasterSendKey, 8, TRUE, TRUE) 
GetAsymmetricStartKey (MasterKey, MasterReceiveKey, 8, FALSE, TRUE) 


The master session keys are never used to encrypt or decrypt data; 


they are only used in the derivation of transient session keys. The 
initial transient session keys are obtained by calling the function 
GetNewKeyFromSHA() (described in [3]): 


GetNewKeyFromSHA (MasterSendKey, MasterSendKey, 8, SendSessionkKey) 
GetNewKeyFromSHA (MasterReceiveKey, MasterReceiveKey, 8, 
ReceiveSessionKey) 


Next, the effective strength of both keys is reduced by setting the 
first three octets to known constants: 


SendSessionKey[0] = ReceiveSessionKey[0] = 0ха1 
SendSessionKey[1] = ReceiveSessionKey[1] = 0x26 
SendSessionKey[2] ReceiveSessionKey[2] 0x9e 


Finally, the RC4 tables are initialized using the new session keys: 


гс4 Кеу (SendRC4key, 8, SendSessionkKey) 
rc4_key (ReceiveRC4key, 8, ReceiveSessionKey) 
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3.2. Generating 56-bit Session Keys 


When used in conjunction with MS-CHAP-2 authentication, the initial 
MPPE session keys are derived from the peer’s Windows NT password. 


The first step is to obfuscate the peer’s password using 
NtPasswordHash() function as described in [8]. 


NtPasswordHash (Password, PasswordHash) 


The first 16 octets of the result are then hashed again using the MD4 
algorithm. 


PasswordHashHash = пай (PasswordHash) 
The first 16 octets of this second hash are used together with the 


NT-Response field from the MS-CHAP-2 Response packet [8] as the basis 
for the master session key: 


GetMasterKey (PasswordHashHash, NtResponse, MasterKey) 


Once the master key has been generated, it is used to derive two 
56-bit session keys, one for sending and one for receiving: 


GetAsymmetricStartKey (MasterKey, MasterSendKey, 8, TRUE, TRUE) 
GetAsymmetricStartKey (MasterKey, MasterReceiveKey, 8, FALSE, TRUE) 


The master session keys are never used to encrypt or decrypt data; 


they are only used in the derivation of transient session keys. The 
initial transient session keys are obtained by calling the function 
GetNewKeyFromSHA() (described in [3]): 


GetNewKeyFromSHA (MasterSendKey, MasterSendKey, 8, SendSessionkKey) 
GetNewKeyFromSHA (MasterReceiveKey, MasterReceiveKey, 8, 
ReceiveSessionKey) 


Next, the effective strength of both keys is reduced by setting the 
first octet to a known constant: 


SendSessionKey[0] = ReceiveSessionKey[0] = 0ха1 
Finally, the RC4 tables are initialized using the new session keys: 


rc4_key(SendRC4key, 8, SendSessionKey) 
rc4_key (ReceiveRC4key, 8, ReceiveSessionKey) 
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3.3. Generating 128-bit Session Keys 


When used in conjunction with MS-CHAP-2 authentication, the initial 
MPPE session keys are derived from the peer's Windows NT password. 


The first step is to obfuscate the peer's password using 
NtPasswordHash() function as described in [8]. 


NtPasswordHash(Password, PasswordHash) 


The first 16 octets of the result are then hashed again using the MD4 
algorithm. 


PasswordHashHash = пай (PasswordHash) 
The first 16 octets of this second hash are used together with the 


NT-Response field from the MS-CHAP-2 Response packet [8] as the basis 
for the master session key: 


GetMasterKey (PasswordHashHash, NtResponse, MasterKey) 


Once the master key has been generated, it is used to derive two 
128-bit master session keys, one for sending and one for receiving: 


GetAsymmetricStartKey (MasterKey, MasterSendKey, 16, TRUE, TRUE) 
GetAsymmetricStartKey (MasterKey, MasterReceiveKey, 16, FALSE, TRUE) 


The master session keys are never used to encrypt or decrypt data; 


they are only used in the derivation of transient session keys. The 
initial transient session keys are obtained by calling the function 
GetNewKeyFromSHA() (described in [3]): 


GetNewKeyFromSHA (MasterSendKey, MasterSendKey, 16, SendSessionKey) 
GetNewKeyFromSHA (MasterReceiveKey, MasterReceiveKey, 16, 
ReceiveSessionKey) 


Finally, the RC4 tables are initialized using the new session keys: 


гс4 Кеу (SendRC4key, 16, SendSessionKey) 
rc4_key (ReceiveRC4key, 16, ReceiveSessionkKey) 
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3.4. Key Derivation Functions 
The following procedures are used to derive the session key. 


/* 
* Pads used in key derivation 


*/ 


SHSpad1[40] = 
(0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; 


SHSpad2[40] - 

(0xf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, 
Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, 
Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, 
Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2, Oxf2}; 


/* 
* "Magic" constants used in key derivations 


Жу 


Magicl[27] = 
10х54, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 
0x68, 0x65, 0x20, Ox4d, 0x50, 0x50, 0x45, 0x20, 0х44, 
Ox61, 0x73, 0x74, 0x65, 0x72, 0x20, Ox4b, 0x65, 0x79); 


Magic2[84] - 

10х4ЁЕ, Ox6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, Ox6c, 0x69, 
0x65, Ox6e, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, Ox2c, 0x20, 
0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, 
0x65, 0x20, 0x73, 0x65, Ox6e, 0x64, 0x20, Ox6b, 0x65, 0x79, 
Ox3b, 0x20, Ox6f, Ox6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x73, 
0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x73, 0x69, 0x64, 0x65, 
0х2с, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, 
0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20, 
Ox6b, 0x65, 0x79, Ox2e}; 


Magic3[84] - 
10х4ЁЕ, Ox6e, 0x20, 0x74, 0x68, 0x65, 0x20, 0x63, Ox6c, 0x69, 
0x65, Ox6e, 0x74, 0x20, 0x73, 0x69, 0x64, 0x65, Ox2c, 0x20, 
0x74, 0x68, 0x69, 0x73, 0x20, 0x69, 0x73, 0x20, 0x74, 0x68, 
0x65, 0x20, 0x72, 0x65, 0x63, 0x65, 0x69, 0x76, 0x65, 0x20, 
Ox6b, 0x65, 0x79, Ox3b, 0x20, Ox6f, Ox6e, 0x20, 0x74, 0x68, 
0x65, 0x20, 0x73, 0x65, 0x72, 0x76, 0x65, 0x72, 0х20, 0x73, 
0x69, 0x64, 0x65, 0х2с, 0x20, 0x69, 0x74, 0x20, 0x69, 0x73, 
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0х20, 0x74, 0x68, 0x65, 0x20, 0x73, 0x65, Ox6e, 0x64, 0x20 
Ox6b, 0x65, 0x79, Ox2e}; 


GetMasterKey( 


IN 
IN 


16-octet  PasswordHashHash, 
24-octet  NTResponse, 


OUT 16-octet  MasterKey ) 


( 


} 


VOI 
Get 
IN 
OUT 
IN 
IN 
IN 
{ 


Zorn 


20-octet Digest 


ZeroMemory (Digest, sizeof (Digest)); 


/* 


х SHSInit(), SHSUpdate() and SHSFinal () 
* are an implementation of the Secure Hash Standard [7]. 


“у 


SHSInit (Context) ; 

SHSUpdate (Context, PasswordHashHash, 
SHSUpdate (Context, NTResponse, 24); 
SHSUpdate (Context, Magicl, 27); 
SHSFinal (Context, Digest); 


MoveMemory (MasterKey, Digest, 16); 


D 

AsymetricStartKey ( 
16-octet MasterKey, 
8-to-16 octet SessionKey, 
INTEGER SessionKeyLength, 
BOOLEAN IsSend, 
BOOLEAN IsServer ) 


20-octet Digest; 
ZeroMemory (Digest, 20); 


if (IsSend) 4 
if (IsServer) 4 
S — Magic3 
) else 4 
S — Magic2 
} 
} else { 
if (IsServer) { 
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/* 
х SHSInit(), SHSUpdate() and SHSFinal () 
* are an implementation of the Secure Hash Standard [7]. 
*/ 

SHSInit (Context); 

SHSUpdate (Context, MasterKey, 16); 

SHSUpdate (Context, SHSpad1, 40); 

SHSUpdate (Context, s, 84); 

SHSUpdate (Context, SHSpad2, 40); 

SHSFinal(Context, Digest); 


MoveMemory (SessionKey, Digest, SessionKeyLength); 


3.5. Sample Key Derivations 


The following sections illustrate 40-, 56- and 128-bit key 
derivations. All intermediate values are in hexadecimal. 


3.5.1. Sample 40-bit Key Derivation 


Initial Values 


UserName - "User" 
=. 55-365 72 
Password = "clientPass" 


= 63 00 6C 00 69 00 65 00 6E 00 
74 00 50 00 61 00 73 00 73 00 


AuthenticatorChallenge - 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 
60 21 32 26 26 28 
PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B ЗА 33 7C 7E 


Challenge = DO 2E 43 86 BC E9 12 26 

NT-Response - 

82 30 9E CD 8D 70 8B 5E АО 8F АА 39 81 CD 83 54 42 33 
11 4A 3D 85 D6 DF 


Step 1: NtPasswordHash(Password, PasswordHash) 
PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE 
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Step 2: PasswordHashHash = MD4 (PasswordHash) 
PasswordHashHash = 41 CO OC 58 4B D2 D9 1C 40 17 A2 Al 2F A5 OF ЗЕ 


Step 3: Derive the master key (GetMasterKey () ) 
MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31 


Step 4: Derive the master send session key (GetAsymmetricStartKey () ) 
SendStartKey40 = 8B 7C DC 14 9B 99 3A 1B 


Step 5: Derive the initial send session key (GetNewKeyFromSHA () ) 
SendSessionkey40 = D1 26 9E C4 9F A6 2E ЗЕ 


Sample Encrypted Message 
rc4(SendSessionkey40, "test message") = 92 91 37 91 7E 58 03 D6 
68 D7 58 98 


3.5.2. Sample 56-bit Key Derivation 


Initial Values 


UserName = "User" 
ees 5 7326572 
Password - "clientPass" 


= 63 00 6C 00 69 00 65 00 6E 00 74 00 50 
00 61 00 73 00 73 00 


AuthenticatorChallenge - 5B 5D 7C 7D 7B ЗЕ 2F 3E 3C 2C 
60 21 32 26 26 28 
PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B ЗА 33 7C 7Е 


Challenge = DO 2E 43 86 BC E9 12 26 

NT-Response - 

82 30 9E CD 8D 70 8B 5E AO 8F AA 39 81 CD 83 54 42 33 
11 4A 3D 85 D6 DF 


Step 1: NtPasswordHash(Password, PasswordHash) 
PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE 


Step 2: PasswordHashHash = MD4 (PasswordHash) 
PasswordHashHash = 41 CO OC 58 4B D2 D9 1C 40 17 A2 Al 2F A5 OF ЗЕ 


Step 3: Derive the master key (GetMasterKey()) 
MasterKey - FD EC E3 71 7A 8C 83 8C B3 88 Ес 27 AE 3C DD 31 


Step 4: Derive the master send session key (GetAsymmetricStartKey () ) 
SendStartKey56 = 8B 7C DC 14 9B 99 3A 1B 
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Step 5: Derive the initial send session key (GetNewKeyFromSHA () ) 
SendSessionKey56 = D1 5C 00 C4 9F Аб 2E ЗЕ 
Sample Encrypted Message 
rc4(SendSessionkey40, "test message") = ЗЕ 10 68 33 FA 44 8D 
A8 42 BC 57 58 


3.5.3. Sample 128-bit Key Derivation 


Initial Values 


UserName = "User" 
= 55 73 65 72 
Password = "clientPass" 


= 63 00 6C 00 69 00 65 00 6E 00 
74 00 50 00 61 00 73 00 73 00 


AuthenticatorChallenge = 5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 
60 21 32 26 26 28 


PeerChallenge = 21 40 23 24 25 5E 26 2A 28 29 5F 2B ЗА 33 7C 7Е 
Challenge = DO 2E 43 86 BC E9 12 26 
NT-Response = 


82 30 9E CD 8D 70 8B 5E AO 8F AA 39 81 CD 83 54 42 33 
11 4A 3D 85 D6 DF 


Step 1: NtPasswordHash (Password, PasswordHash) 
PasswordHash = 44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE 


Step 2: PasswordHashHash = MD4 (PasswordHash) 
PasswordHashHash = 41 CO OC 58 4B D2 D9 1C 40 17 A2 Al 2F A5 OF ЗЕ 


Step 2: Derive the master key (GetMasterKey () ) 
MasterKey = FD EC E3 71 7A 8C 83 8C B3 88 E5 27 AE 3C DD 31 


Step 3: Derive the send master session key (GetAsymmetricStartKey () ) 
SendStartKey128 = 8B 7C DC 14 9B 99 3A 1B Al 18 CB 15 3F 56 DC CB 


Step 4: Derive the initial send session key (GetNewKeyFromSHA () ) 
SendSessionKey128 = 40 5C B2 24 7A 79 56 Еб E2 11 00 7A E2 7B 22 D4 


Sample Encrypted Message 


rc4(SendSessionkey128, "test message") = 81 84 83 17 DF 68 
84 62 72 FB 5A BE 
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4. Deriving MPPE Session Keys from TLS Session Keys 


The Extensible Authentication Protocol (EAP) [10] is a PPP extension 
that provides support for additional authentication methods within 
PPP. Transport Level Security (TLS) [11] provides for mutual 
authentication, integrity-protected ciphersuite negotiation and key 
exchange between two endpoints.  EAP-TLS [12] is an EAP 
authentication type which allows the use of TLS within the PPP 
authentication framework. The following sections describe the 
methods used to derive initial session keys from TLS session keys. 
56-, 40- and 128-bit keys are derived using the same algorithm. The 
only difference is in the length of the keys and their effective 
strength: 56- and 40-bit keys are 8 octets in length, while 128-bit 
keys are 16 octets long. Separate keys are derived for the send and 
receive directions of the session. 


4.1. Generating 40-bit Session Keys 


When MPPE is used in conjunction with EAP-TLS authentication, the TLS 
master secret is used as the master session key. 


The algorithm used to derive asymmetrical master session keys from 
the TLS master secret is described in [12]. The master session keys 
are never used to encrypt or decrypt data; they are only used in the 
derivation of transient session keys. 


Implementation Note 


If the asymmetrical master keys are less than 8 octets in length, 
they MUST be padded on the left with zeroes before being used to 
derive the initial transient session keys. Conversely, if the 
asymmetrical master keys are more than 8 octets in length, they 
must be truncated to 8 octets before being used to derive the 
initial transient session keys. 


The initial transient session keys are obtained by calling the 
function GetNewKeyFromSHA() (described in (31): 


GetNewKeyFromSHA (MasterSendKey, MasterSendKey, 8, SendSessionkKey) 
GetNewKeyFromSHA (MasterReceiveKey, MasterReceiveKey, 8, 
ReceiveSessionKey) 


Next, the effective strength of both keys is reduced by setting the 
first three octets to known constants: 


SendSessionKey[0] = ReceiveSessionKey[0] = 0хр1 
SendSessionKey[1] = ReceiveSessionKey[1] = 0x26 
SendSessionKey[2] = ReceiveSessionKey[2] = 0х9Е 
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Finally, the RC4 tables are initialized using the new session keys: 


rc4_key(SendRC4key, 8, SendSessionkey) 
rc4_key (ReceiveRC4key, 8, ReceiveSessionKey) 


4.2. Generating 56-bit Session Keys 


When MPPE is used in conjunction with EAP-TLS authentication, the TLS 
master secret is used as the master session key. 


The algorithm used to derive asymmetrical master session keys from 
the TLS master secret is described in [12]. The master session keys 
are never used to encrypt or decrypt data; they are only used in the 
derivation of transient session keys. 


Implementation Note 


If the asymmetrical master keys are less than 8 octets in length, 
they MUST be padded on the left with zeroes before being used to 
derive the initial transient session keys. Conversely, if the 
asymmetrical master keys are more than 8 octets in length, they 
must be truncated to 8 octets before being used to derive the 
initial transient session keys. 


The initial transient session keys are obtained by calling the 
function GetNewKeyFromSHA() (described in [3]): 


GetNewKeyFromSHA (MasterSendKey, MasterSendKey, 8, SendSessionkey) 
GetNewKeyFromSHA (MasterReceiveKey, MasterReceiveKey, 8, 


ReceiveSessionKey) 


Next, the effective strength of both keys is reduced by setting the 
initial octet to a known constant: 


SendSessionKey[0] = ReceiveSessionKey[0] = OxD1 


Finally, the RC4 tables are initialized using the new session keys: 


rc4_key (SendRC4key, 8, SendSessionkKey) 
rc4_key (ReceiveRC4key, 8, ReceiveSessionKey) 


4.3. Generating 128-bit Session Keys 


When MPPE is used in conjunction with EAP-TLS authentication, the TLS 
master secret is used as the master session key. 
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The algorithm used to derive asymmetrical master session keys from 
the TLS master secret is described in [12]. Note that the send key 
on one side is the receive key on the other. 


The master session keys are never used to encrypt or decrypt data; 
they are only used in the derivation of transient session keys. 


Implementation Note 


If the asymmetrical master keys are less than 16 octets in length, 
they MUST be padded on the left with zeroes before being used to 
derive the initial transient session keys. Conversely, if the 
asymmetrical master keys are more than 16 octets in length, they 
must be truncated to 16 octets before being used to derive the 
initial transient session keys. 


The initial transient session keys are obtained by calling the 
function GetNewKeyFromSHA() (described in [3]): 


GetNewKeyFromSHA (MasterSendKey, MasterSendKey, 16, SendSessionKkey) 
GetNewKeyFromSHA (MasterReceiveKey, MasterReceiveKey, 16, 
ReceiveSessionKey) 


Finally, the RC4 tables are initialized using the new session keys: 


rc4_key (SendRC4key, 16, SendSessionKey) 
rc4_key (ReceiveRC4key, 16, ReceiveSessionKey) 


5. Security Considerations 
5.1. MS-CHAP Credentials 


Because of the way in which 40-bit keys are derived from М5-СНАР-1 
credentials, the initial 40-bit session key will be identical in all 
sessions established under the same peer credentials. For this 
reason, and because RC4 with a 40-bit key length is believed to be a 
relatively weak cipher, peers SHOULD NOT use 40-bit keys derived from 
the LAN Manager password hash (as described above) if it can be 
avoided. 


Since the MPPE session keys are derived from user passwords (in the 
М5- CHAP-1 and М5-СНАР-2 cases), care should be taken to ensure the 
selection of strong passwords and passwords should be changed 
frequently. 
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5.2.  EAP-TLS Credentials 


The strength of the session keys is dependent upon the security of 
the TLS protocol. 


The EAP server may be on a separate machine from the PPP 
authenticator; if this is the case, adequate care must be taken in 
the transmission of the EAP-TLS master keys to the authenticator. 
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This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 
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